The 3rd Generation Partnership Project (3GPP) has been standardizing Cellular Internet of Things (CIoT). CIoT covered by 3GPP includes Long Term Evolution enhanced Machine to Machine (LTE eMTC) and Narrowband IoT (NB-IoT). The characteristic features of LTE eMTC and NB-IoT include ultra-low User Equipment (UE) power consumption, a large number of devices per cell, narrowband spectrum, and extended coverage. In LTE eMTC (Category M), UE Radio Frequency (RF) bandwidth is defined as 1.4 MHz. Meanwhile, in NB-IoT, it is assumed that downlink and uplink peak rates are 200 kbps or 144 kbps, and UE RF bandwidth is about 200 kHz (effective bandwidth is 180 kHz) in both uplink and downlink for further cost optimization, low power consumption, and coverage extension.
Non-Patent Literature 1 describes several communication architecture solutions for infrequent small data transmission in the NB-IoT. These solutions include an architecture for data transmission through the control plane (i.e., Solution 2) and an architecture for data transmission through the user plane (i.e., Solution 18) involving suspension and resumption of a Radio Resource Control (RRC) connection. In Non Patent Literature 1, support of the solution 2 is mandatory for both the UE and the network, while support of the solution 18 is optional for both the UE and the network.
The solution 2 and solution 18 are also referred to as “Data over NAS (DoNAS)” and “AS context caching”, respectively. Alternatively, the solution 2 and solution 18 are also referred to as “Control Plane CIoT EPS optimisation” and “User Plane CIoT EPS optimisation”, respectively.
The architecture according to the solution 18 provides infrequent small data transmission on the user plane. The architecture according to the solution 18 has the feature of reusing information obtained from the previous RRC connection for the subsequent RRC connection setup, thereby reducing the signaling required for UE Radio Resource Control (RRC) state transition.
Specifically, a UE enters the RRC-Idle mode from the RRC-Connected mode and retains information about the RRC connection (e.g., an Access Stratum Security Context, bearer related information (incl. RoHC state information), and L2/1 parameters when applicable) while it is in RRC-Idle mode. Similarly, an eNB retains information about the RRC connection of the UE (e.g., Access Stratum Security Context, bearer-related information (incl. RoHC state information), and L2/1 parameters when applicable). Further, the eNB and the Mobility Management Entity (MME) retain S1AP UE Contexts. Furthermore, the eNB retains S1-U tunnel addresses.
When returning to the RRC-Connected mode, the UE sends an RRC Connection Resume Request to the eNB. The eNB restores a DRB(s), a security context, an S1AP connection, and an S1-U tunnel(s) based on the previously retained information about the RRC connection. Further, the eNB informs the MME of a UE state change using a new S1AP message (e.g., S1AP: UE Context Resume Request). The MME returns the Evolved Packet System (EPS) Connection Management (ECM) state of the UE to the ECM-Connected state and then sends a Modify Bearer Request message to the Serving Gateway (S-GW). As a result, the S-GW recognizes that the UE is in the connected state and hence becomes ready to transmit downlink data towards the UE.
In the solution 18, the UE can return to RRC-Connected and ECM-Connected without transmitting a NAS message (i.e., Service Request). Further, as compared with the legacy RRC connection setup procedure, the following RRC messages can be removed:                RRC Connection Setup Complete;        RRC Security Mode Command;        RRC Security Mode Complete;        RRC Connection Reconfiguration; and        RRC Connection Reconfiguration Complete.        
A Resume ID is used to enable suspension and resumption of an RRC connection. The Resume ID is used to distinguish between suspended UEs, RRC connections, or UE contexts. The eNB includes the Resume ID in a downlink RRC message (e.g., RRC Connection Release) for instructing a UE to suspend RRC connection. The UE transmits an RRC connection Resume Request message containing the Resume ID when resuming the RRC connection.
In addition, it is expected that the UE in RRC-Idle performs cell reselection, move to a cell of another eNB, and then makes an RRC Connection Resume Request in this cell. In this case, the another eNB (i.e., target eNB) specifies, based on the Resume ID, an eNB (i.e., source eNB) which manages a cell in which the UE suspends its RRC connection. The target eNB transmits a RETRIEVE UE CONTEXT REQUEST message including the Resume ID, the Short MAC-I, and the E-UTRAN Cell Identifier (ECGI) to request the source eNB to send a UE context. In response to this message, the source eNB determines whether the UE context matches (i.e., whether resumption succeeds). When the UE context matches (or resumption succeeds), the source eNB sends the UE context to the target eNB via a RETRIEVE UE CONTEXT RESPONSE message. The target eNB further sends a UE CONTEXT RESUME REQUEST message to an MME. The MME instructs an S-GW/Packet Data Network Gateway (P-GW) to reestablish (or modify) a bearer and transmits a UE CONTEXT RESUME RESPONSE to the target eNB. Consequently, the target eNB and the UE can resume data transmission and reception.
Currently, it is assumed that the Resume ID consists of a 20-bit length eNB ID and a 20-bit length UE ID and thus has the 40-bit length. When an initial uplink RRC message (i.e., RRC Connection Resume Request message) containing the 40-bit length Resume ID is transmitted by the third message (Msg3) of the random access, the minimum size (i.e., 56 bits) is insufficient for the Msg3 size, and it requires 80 bits or 88 bits.
The 3GPP further studies applying the above signaling expansion (i.e., the solution 2 and the solution 18) regarding NB-IoT also to a non-NB-IoT system (e.g., LTE). Non-NB-IoT UEs are, for example, LTE eMTC (Category M) UEs.
In the case of Non-NB-IoT UEs, if a 40-bit Resume ID is used, the eNB needs to allocate 80-bit or 88-bit uplink resources (i.e., Physical Uplink Shared Channel (PUSCH) resources) for the third message (Msg3) transmission, via the second message (Msg2) of the random access, i.e., an uplink (UL) grant included in the random access response. Meanwhile, non-NB-IoT UEs need to always transmit an 80-bit or 88-bit Msg3 regardless of the purpose thereof, i.e., not only for an RRC Connection Resume Request, an RRC Connection Request and an RRC Connection Reestablishment Request. That is, an RRC Connection Request or an RRC Connection Reestablishment Request is transmitted with padding bits, which causes waste of radio resources.
In addition, if the size of the third message (Msg3) of the random access procedure increases, a coverage guaranteed by the legacy LTE is not likely to be guaranteed. That is, an increase in the Msg3 size would restrict the LTE UL coverage for non-NB-IoT (e.g., LTE) UEs.
Non-Patent Literature 2 proposes using only part of the 40-bit Resume ID to avoid an impact on the UL coverage caused when the 40-bit Resume ID is always used for non-NB-IoT UEs. Specifically, Non-Patent Literature 2 proposes that non-NB-IoT UEs transmit a truncated Resume ID (i.e., 25 least significant bits (LSB) of the 40-bit Resume ID) via a Msg3 for RRC resume. Furthermore, Non-Patent Literature 2 proposes introducing a Resume ID type indication in the system information for non-NB-IoT UEs. The Resume ID type indication indicates which one of the full resume ID and the truncated resume ID shall be used by non-NB-IoT UEs to transmit via a Msg3 for RRC resume.
Furthermore, the 3GPP studies reusing the legacy PRACH partitioning to enable an eNB to distinguish whether a received PRACH preamble is intended for transmission of an 80-bit (or 88-bit) Msg3 (i.e., an RRC Connection Resume Request containing the full resume ID) or for transmission of a 56-bit Msg3 (i.e., an RRC Connection Request, an RRC Connection Reestablishment Request, or an RRC Connection Resume Request containing the truncated resume ID).
Specifically, when non-NB-IoT UEs transmit a Msg3 which carries an RRC message containing the full resume ID, the non-NB-IoT UEs select a Random-Access-Preambles group associated with the Msg3 size of 80 bits or more and then select a preamble from the selected Preambles group. On the other hand, when non-NB-IoT UEs transmit a Msg3 composed of 56 bits or less and carrying an RRC message that contains the truncated resume ID or carrying a legacy RRC Connection Request message or an RRC Connection Reestablishment Request message, the non-NB-IoT UEs select another Random-Access-Preambles group associated with the Msg3 size of 56 bits and then select a preamble from the selected Preambles group. The eNB can determine, based on the received PRACH preamble, which PUSCH resource associated with one of the 56-bit Msg3 and the 80-bit Msg3 needs to be allocated.